1. The Field of the Invention
The present invention relates to the fields of distributed computing systems, client-server computing and object-oriented programming. More specifically, the present invention relates to creating and installing applications on a distributed object system.
2. The Relevant Art
Object-oriented programming methodologies have received increasing attention over the past several years in response to the increasing tendency for software developed using traditional programming methods to be delivered late and over budget. One problem with traditional programming techniques stems from the emphasis placed on procedural models and "linear" code that often is extremely difficult to design and maintain. Generally, large programs created using traditional methods are "brittle", that is, even small changes can affect all elements of the programming code. Thus, minor changes made to the software in response to user demands can require major redesign and rewriting of the entire program.
Object-oriented programming strategies tend to avoid these problems because object methodologies focus on manipulating data rather than procedures; thus providing the programmer with a more intuitive approach to modeling real world problems. In addition, objects encapsulate related data and procedures so as to hide that information from the remainder of the program by allowing access to the data and procedures only through the object's interface. Hence changes to the data and or procedures of te object are relatively isolated from the remainder of the program. This provides code that Is more easily maintained as compared to code written using traditional methods, as changes to an object's code do not affect the code in the other objects. Furthermore, the inherent modular nature of objects allows individual objects to be reused in different programs. Thus, programmers can develop libraries of "tried and true" objects that can be used over and over again in different applications. This increases software reliability while decreasing development time, as reliable programming code may be used repeatedly.
The object metaphor in distributed systems is a useful technique as it separates the object's interface from its implementation; thereby allowing software designers to take advantage of the functionalities of various objects available to them without having to worry about the details of the object's implementation. The programmer need only be aware of the object's interface. In addition, object-oriented distributed systems allow for object implementations that may reside on different computing platforms that have been connected through a network. Thus, a programmer working on one machine of a network may make a call to an object about which the programmer only knows the object's interface with the confidence that at the appropriate time that the remote object will be accessed and return its data so that the programmers code will function properly. Such a system thus maximizes the inherent advantages of object-oriented methodologies by taking full advantage of their modularity and encapsulation.
Although the advantages to employing object-oriented programming methodologies through distributed object systems are significant, there remain major hurdles to their implementation. In general, the goal of implementing the re-use of software during the programming process, even in the context of object programming, is difficult to achieve. Typically, programmers are reluctant to use code about which their understanding is minimal or even nonexistent. This is compounded in distributed object systems as the developer(s) of the code may not be easily reached to provide comments and instruction to the programmer whose task is to develop a new application. Thus, although much useful code may be available to the programmer throughout the distributed object system that programmer may not be able to take full advantage of it, thus being forced to rewrite sections of code that have already been developed.
Present methodologies for sharing code are inadequate in the distributed object model. Current methods for sharing object code include the use of shared libraries, publicly available directories of header files, and the wide-spread distribution of documentation (either electronically or by hard copy). These methods, however, do not lend themselves well to adaptation in a distributed object environment in which the basic elements being manipulated are not file-based but rather are interface-based. Also, methods for re-using objects in a distributed object system should seek to increase the user's sense of a "community" of programmers and the code they produce. Thus, systems seeking to increase the re-use of objects in a distributed object system should facilitate the user's determination of an object's identity, its purpose, and its method of use.
As described in co-pending U.S. patent application Ser. No. 08/414,240, incorporated herein by reference for all purposes, another challenge to programming in a distributed object environment is the need to provide large amounts of "boilerplate" type computer code so that objects and applications developed for use in the distributed object system can function properly within that system; in particular, the need to provide basic computer code structures to enable ordinary objects (i.e., C++objects) to function as distributed objects. In addition, however, the programmer seeking to maximize the re-use of existing objects and computer code in the distributed objects system is faced with similar although slightly different challenges. When a programmer wishes to employ an object in an application being developed, the programmer must indicate basic information pertaining to the object such as the name of the object's factory and must provide various initialization data. In addition, a variety of makefiles, header files, and library dependencies must be accounted for in the code before that code is forwarded to additional facilities such as described in co-pending U.S. patent application Ser. No. 08/414,240. Additional details that must be provided by the programmer include various exception handling, debugging, and tracing support code. Again, although the methods and code required are generally known to those of skill in the art, the implementation of such routines is laborious, repetitive, and prone to error. Thus, the development of appropriately coded object applications is an extremely time consuming and painstaking task. It would therefore be preferable to automate the incorporation of such "housekeeping" code.
Unfortunately, most programming objects currently in existence are not written to support the functionalities required for placement on a distributed operating system. Thus, the implementation of existing objects on such systems would require much retooling of the existing object software. This would lessen the advantages afforded by object programming methodologies as existing programming objects would not be easily available in distributed object systems.
An additional difficulty with implementing distributed objects on distributed object systems arises from the need to inform the system of the presence of the objects at the time of their installation. Since all client requests are processed through the object request broker, or ORB, the ORB must have knowledge of the existence of the objects. Furthermore, it is preferable in distributed object systems to have functionalities that allow for a clear distinction between objects that are in the development phase and objects that are available to users on the distributed object system generally. Providing such awareness poses various difficulties for the programmer who must bear the burden of implementing a wide variety of "housekeeping" operations to take advantage of the benefits of the distributed object system.
The full promise of object-oriented methodologies, especially the advantages afforded by their modularity, have yet to be achieved. In particular, it would be highly desirable to allow programmers and other users the ability to create and install distributed objects in a relatively transparent fashion so that objects created in different programming languages and/or objects residing on different computing platforms can be made available on distributed object systems without extensive modification of programming code or placing an undue burden on the user. Thus, it would be preferable to have a system capable of handling the formation and installation of distributed objects that minimizes the need for the programmer or the user to be familiar with the details of distributed object systems. More preferable is a system in which programming objects that are not distributed can be transformed into a distributed object relatively transparently with respect to the programmer or the user.